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IESG Note 


This RFC is not a candidate for any level of Internet Standard. The 
IETF disclaims any knowledge of the fitness of this RFC for any 
purpose and in particular notes that the decision to publish is not 
based on IETF review for such things as security, congestion control, 
or inappropriate interaction with deployed protocols. The RFC Editor 
has chosen to publish this document at its discretion. Readers of 
this document should exercise caution in evaluating its value for 
implementation and deployment. See RFC 3932 for more information. 


Abstract 


This document describes the set of Remote Authentication Dial-In User 
Service Vendor-Specific Attributes (RADIUS VSAs) defined by the DSL 
Forum. 


These attributes are designed to transport Digital Subscriber Line 
(DSL) information that is not supported by the standard RADIUS 
attribute set. It is expected that this document will be updated if 
and when the DSL Forum defines additional vendor-specific attributes, 
Since its primary purpose is to provide a reference for DSL equipment 
vendors wishing to interoperate with other vendors' products. 
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1. Introduction 


The DSL Forum has created additional RADIUS [RFC2865] [RFC2866] 
vendor-specific attributes to carry DSL line identification and 
characterization information. This information is forwarded from the 
Access Node/DSLAM to the BRAS via Vendor-Specific PPPoE Tags 
[RFC2516], DHCP Relay Options [RFC3046], and Vendor-Specific 
Information Suboptions [RFC4243]. This document describes the 
subscriber line identification and characterization information and 
its mapping to RADIUS VSAs by the BRAS. 


The information acquired may be used to provide authentication and 
accounting functionality. It may also be collected and used for 
management and troubleshooting purposes. 


2. Terminology 


The following sections define the usage and meaning of certain 
specialized terms in the context of this document. 


2.1. Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.2. Technical Terms and Acronyms 


AAL5 
ATM Adaption Layer 5 [ITU.1363-5.1996] 


Access Node/DSLAM 
The Access Node/DSLAM is a DSL signal terminator that contains a 
minimum of one Ethernet interface that serves as its northbound 
interface into which it aggregates traffic from several 
Asynchronous Transfer Mode (ATM)-based (subscriber ports) or 
Ethernet-based southbound interfaces. 


BNG 
Broadband Network Gateway. A BNG is an IP edge router where 
bandwidth and QoS policies are applied; the functions performed by 
a BRAS are a superset of those performed by a BNG. 
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BRAS 
Broadband Remote Access Server. A BRAS is a BNG and is the 
aggregation point for the subscriber traffic. It provides 


aggregation capabilities (e.g., IP, PPP, Ethernet) between the 
access network and the core network. Beyond its aggregation 
function, the BRAS is also an injection point for policy 
management and IP QoS in the access network. 


DSL 
Digital Subscriber Line. DSL is a technology that allows digital 
data transmission over wires in the local telephone network. 


DSLAM 
Digital Subscriber Line Access Multiplexer. DSLAM is a device 
that terminates DSL subscriber lines. The data is aggregated and 


forwarded to ATM- or Ethernet-based aggregation networks. 


FCS 


Frame Check Sequence. The FCS is a checksum added to an Ethernet 
frame for error detection/correction purposes. 


IPOA 
IP over ATM 


IWF 


Interworking Function. The set of functions required for 
interconnecting two networks of different technologies (e.g., ATM 
and Ethernet).  IWF is utilized to enable the carriage of PPP over 
ATM (PPPOA) traffic over PPPoE. 


LLC 
Logical Link Control 
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3. Attributes 


The following subsections describe the Attributes defined by this 
document. These Attributes MAY be transmitted in one or more RADIUS 
Attributes of type Vendor-Specific [RFC2865]. More than one 
attribute MAY be transmitted in a single Vendor-Specific Attribute; 
if this is done, the attributes SHOULD be packed as a sequence of 
Vendor-Type/Vendor-Length/Value triples following the initial Type, 
Length, and Vendor-Id fields. 


3.1. DSL Forum RADIUS VSA Definition 
Description 
This Attribute functions as a "container", encapsulating one or 
more vendor-specific sub-attributes; the encoding follows the 


recommendations in [RFC2865]. 


A summary of the generic DSL Forum VSA format is shown below. The 
fields are transmitted from left to right. 


0 1 2 3 
ORD 2: 3% 4s 010011 899,00 1.2 3495 06: 8 9:074. 2: 3-45. 16: 807900: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | Length | Vendor-Id 
*—R—4—4-—4-—4-t-t-t-t----t-t-t-t-t-—t—L-L-4— —4——4-4-4-4-4-4-4-4 
Vendor-Id (cont) | Sub-Attribute(s)... 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type 
26 for Vendor-Specific 
Length 
This field MUST be set equal to the sum of the Vendor-Length 
fields of the sub-attributes contained in the Vendor-Specific 
Attribute, plus six (Type + Length + Vendor-Id). 


Vendor-Id 


This field MUST be set to decimal 3561, the enterprise number 
assigned to the ADSL Forum [IANA]. 


Sub-Attributes 


This field MUST contain one or more DSL Forum Vendor-Specific 
sub-attributes, as specified below. 
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3.2. DSL Forum Vendor Specific Sub-Attribute Encoding 


A summary of the sub-attribute format is shown below. The fields are 
transmitted from left to right. 


0 1 2 
012345678°9012345678 90 
M o 4-4-4 $$$ tt  —— — 2 

| Vendor-Type | Vendor-Length | Value... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 


Vendor-Type 


The Vendor-Type field is one octet in length and contains the 
sub-attribute type, as assigned by the DSL Forum. 


Vendor-Length 


The Vendor-Length field is one octet and indicates the length of 
the entire sub-attribute, including the Vendor-Type, 
Vendor-Length, and Value fields. 


Value 


The Value field is zero or more octets and contains information 
specific to the sub-attribute. The format and length of the Value 
field is determined by the Vendor-Type and Vendor-Length fields. 
The format of the value field is one of 2 data types, string or 
integer [RFC2865]. 


3.3. Sub-attribute Definitions 


The following sub-sections define the DSL Forum vendor-specific sub- 
attributes. 


3.3.1.  Agent-Circuit-Id 
Description 
This Attribute contains information describing the subscriber 
agent circuit identifier corresponding to the logical access loop 
port of the Access Node/DSLAM from which a subscriber's requests 


are initiated. It MAY be present in both Access-Request and 
Accounting-Request packets. 


A summary of the Agent-Circuit-Id Attribute format is shown below. 
The fields are transmitted from left to right. 
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0 1 2 3 
Qui. 2-3-4 5.6 7 8-9-0-1.2 3 4 5-6 7 8.9.0 1.2 3.4-5 6 7 8 9.0 1 
(————————————————————A^A^^———————————MÀ o o H 

| Vendor-Type | Vendor-Length | String... 
——————52————————————^—R—————O—————— € 


Vendor-Type 

1 for Agent-Circuit-Id 
Vendor-Length 

<= 65 
String 


The String field contains information about the Access-Node to 
which the subscriber is attached, along with an identifier for the 
subscriber's DSL port on that Access-Node. 


The exact syntax of the string is implementation dependent; 
however, a typical practice is to subdivide it into two or more 
Space-separated components, one to identify the Access-Node and 
another the subscriber line on that node, with perhaps an 
indication of whether that line is Ethernet or ATM. Example 
formats for this string are shown below. 


"Access-Node-Identifier atm slot/port:vpi.vci" 
(when ATM/DSL is used) 


"Access-Node-Identifier eth slot/port[:vlan-id]" 
(when Ethernet/DSL is used) 


An example showing the slot and port field encoding is given 
below: 


"[Relay-identifier] atm 3/0:100.33" 
(slot = 3, port = 0, vpi = 100, vci - 33) 


The Access-Node-Identifier is a unique ASCII string that does not 
include 'space' characters. The syntax of the slot and port 
fields reflects typical practices currently in place. The slot 
identifier does not exceed 6 characters in length, and the port 
identifier does not exceed 3 characters in length using a ’\’ as a 
delimiter. 
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3. 


3 


The exact manner in which slots are identified is Access 
Node/DSLAM implementation dependent. The vpi, vci, and vlan-id 
fields (when applicable) are related to a given access loop 
(U-interface). 


.2. Agent-Remote-Id 
Description 


The Agent-Remote-Id Attribute contains an operator-specific, 
statically configured string that uniquely identifies the 
subscriber on the associated access loop of the Access Node/DSLAM. 


In a typical subscriber environment, multiple attributes can be 
used to identify the user, among others: Username (for example, as 
defined on a PPP client); Agent-Circuit-Id (a static, pre-defined 
string sent from the Access Node/DSLAM); Agent-Remote-Id (an 
operator-defined string configured on and sent by the Access 
Node/DSLAM) . 


This Attribute MAY be included in both Access-Request and 
Accounting-Request packets. 


A summary of the Agent-Remote-Id Attribute format is shown below. 
The fields are transmitted from left to right. 


0 1 2 3 
001.2 3456 1 89.012 3 o45. 6 7:8 90 123456679899 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Vendor-Type | Vendor-Length | String... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 

2 for Agent-Remote-Id 
Vendor-Length 

<= 65 
String 

This value of this field is entirely open to the service 


provider's discretion. For example, it MAY contain a subscriber 
billing identifier or telephone number. 
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3.3.3.  Actual-Data-Rate-Upstream 
Description 


This Attribute contains the actual upstream train rate of a 
subscriber’s synchronized DSL link. It MAY be included in both 
Access-Request and Accounting-Request packets. 


A summary of the Actual-Data-Rate-Upstream Attribute format is shown 
below. The fields are transmitted from left to right. 


0 I 2 3 
0:1..2-3.4 5-6 y 8.9 0 1.2 3.4 5.6.7 8. 9 0 L2 3 4 5-6 78 9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 

129 (0x81) for Actual-Data-Rate-Upstream 
Vendor-Length 

6 
Value 

This field contains a 4-byte unsigned integer, indicating the 


subscriber's actual data rate upstream of a synchronized DSL link. 
The rate is coded in bits per second. 


3.3.4.  Actual-Data-Rate-Downstream 
Description 
This Attribute contains the actual downstream train rate of a 
subscriber's synchronized DSL link. It MAY be included in both 


Access-Request and Accounting-Request packets. 


A summary of the Actual-Data-Rate-Downstream Attribute format is 
shown below. The fields are transmitted from left to right. 
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0 1 2 3 
Quod 2:3) 4-56 7 8.9 0.1.2 3 4 5-6.7 89.9.0. 1.2 3.4-5 6 7 8 9.01 
PA A A A A A A A A A A A A A A A A A A A O A o o o o € 

| Vendor-Type | Vendor-Length | Value 

PA A A A A A A 4-4-4 A A A ppp pip A pip ip o o o o o 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Vendor-Type 
130 (0x82) for Actual-Data-Rate-Downstream 

Vendor-Length 
6 

Value 
This field contains a 4-byte unsigned integer, indicating the 
subscriber's actual data rate downstream of a synchronized DSL 
link. The rate is coded in bits per second. 

3.3.5. Minimum-Data-Rate-Upstream 

Description 
This Attribute contains the subscriber's operator-configured 
minimum upstream data rate. It MAY be included in Accounting- 


Request packets. 


A summary of the Minimum-Data-Rate-Upstream Attribute format is shown 
below. The fields are transmitted from left to right. 


0 1 2 3 
0. 2-3 4-5 76-7 8: 9 0. 1.2.3 4-5-6-77:8. 9:0 5L 2.345,76. 5789-40" 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ — o o o o + + 
| Vendor-Type | Vendor-Length | Value 
dd A AO O A AO O A O O O O AO RO O hd O O AO A A O o o o o ++ + 
Value (cont'd.) | 
+-4-4-4-4-4-4-4-4-4+-4-4-4-4-4-4-4 


Vendor-Type 
131 (0x83) for Minimum-Data-Rate-Upstream 
Vendor-Length 


6 
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Value 
This field contains a 4-byte unsigned integer, indicating the 
subscriber's minimum upstream data rate (as configured by the 
operator). The rate is coded in bits per second. 

3.3.6. Minimum-Data-Rate-Downstream 

Description 
This Attribute contains the subscriber's operator-configured 
minimum downstream data rate. It MAY be included in Accounting- 


Request packets. 


A summary of the Minimum-Data-Rate-Downstream Attribute format is 
shown below. The fields are transmitted from left to right. 


0 1 2 3 
0 1.2.3.4 5.0 7 89 90 12 34 5618 9-0 1 2.34 5 6 T 8.9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 
132 (0x84) for Minimum-Data-Rate-Downstream 
Vendor-Length 
6 
Value 
This field contains a 4-byte unsigned integer, indicating the 
subscriber's minimum downstream data rate (as configured by the 
operator). The rate is coded in bits per second. 
3.3.7.  Attainable-Data-Rate-Upstream 


Description 


This Attribute contains the subscriber's attainable upstream data 
rate. It MAY be included in Accounting-Request packets. 


A summary of the Attainable-Data-Rate-Upstream Attribute format is 
shown below. The fields are transmitted from left to right. 
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0 1 2 3 
0.1.2.3 45 6789 01234 °5-6 789 012 34.5 67 8 9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 

133 (0x85) for Attainable-Data-Rate-Upstream 
Vendor-Length 

6 


Value 


This field contains a 4-byte unsigned integer, indicating the 
subscriber's actual DSL attainable upstream data rate. The rate 
is coded in bits per second. 


3.3.8. Attainable-Data-Rate-Downstream 
Description 


This Attribute contains the subscriber's attainable downstream 
data rate. It MAY be included in Accounting-Request packets. 


A summary of the Attainable-Data-Rate-Downstream Attribute format is 
shown below. The fields are transmitted from left to right. 


0 1 2 3 
0 1.2.3.4 5.6 189.012 34.5060 7:8 9012.345 678.9 01 
I A O AO A O O A O O O O A RO O A O O O O O O P — o o o + + 
| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ O O A O A A o o o o o + + 
Value (cont'd.) | 
+-4-4-4-4-4-4-4-4-4+-4-4-4-4-4-4-4 


Vendor-Type 
134 (0x86) for Attainable-Data-Rate-Downstream 
Vendor-Length 


6 
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Value 


This field contains a 4-byte unsigned integer, indicating the 
subscriber's actual DSL attainable downstream data rate. The rate 
is coded in bits per second. 


3.3.9. Maximum-Data-Rate-Upstream 
Description 
This Attribute contains the subscriber's maximum upstream data 
rate, as configured by the operator. It MAY be included in 


Accounting-Request packets. 


A summary of the Maximum-Data-Rate-Upstream Attribute format is shown 
below. The fields are transmitted from left to right. 


0 1 2 3 
0 1.2.3.4 50 7 9 9.01 2 34.5 6 48 9-0 12.34 5» 6 T.8.9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 
135 (0x87) for Maximum-Data-Rate-Upstream 
Vendor-Length 
6 
Value 
This field is a 4-byte unsigned integer, indicating the numeric 
value of the subscriber's DSL maximum upstream data rate. The 
rate is coded in bits per second. 
3.3.10. Maximum-Data-Rate-Downstream 
Description 
This Attribute contains the subscriber's maximum downstream data 


rate, as configured by the operator. It MAY be included in 
Accounting-Request packets. 
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A summary of the Maximum-Data-Rate-Downstream Attribute format is 
shown below. The fields are transmitted from left to right. 


0 1 2 3 
Od .2:.3 42520" PS O95 O ENS e E -6- 38 OP O ESA 6h A ES O 
dh A A A A A +H 

| Vendor-Type | Vendor-Length | Value 

+-+-+-+-+-+-+-+-+-+-+- A o hh hh A + o o +++ 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ 


Vendor-Type 
136 (0x88) for Maximum-Data-Rate-Downstream 

Vendor-Length 
6 

Value 
This field is a 4-byte unsigned integer, indicating the numeric 
value of the subscriber's DSL maximum downstream data rate. The 
rate is coded in bits per second. 

3.3.11. Minimum-Data-Rate-Upstream-Low-Power 

Description 
This Attribute contains the subscriber's minimum upstream data 
rate in low power state, as configured by the operator. It MAY be 
included in Accounting-Request packets. 

A summary of the Minimum-Data-Rate-Upstream-Low-Power Attribute 

format is shown below. The fields are transmitted from left to 

right. 

0 1 2 3 
0.1.2.3 4567989 9012 345.678 9 0122349570789. 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| vendor-Type | Vendor-Length | Value 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Vendor-Type 


137 (0x89) for Minimum-Data-Rate-Upstream-Low-Power 
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Vendor-Length 
6 
Value 


This field is a 4-byte unsigned integer, indicating the numeric 
value of the subscriber's DSL minimum upstream data rate when in 
low power state (L1/L2). The rate is coded in bits per second. 


3.3.12. Minimum-Data-Rate-Downstream-Low-Power 
Description 


This Attribute contains the subscriber's minimum downstream data 
rate in low power state, as configured by the operator. It MAY be 
included in Accounting-Request packets. 


A summary of the Minimum-Data-Rate-Downstream-Low-Power Attribute 
format is shown below. The fields are transmitted from left to 
right. 


0 1 2 3 
0.1.2.3.4 5.6 7 8 9.0.12 3.4 56 789 012 534-567 8 9.0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 

138 (0x8A) for Minimum-Data-Rate-Downstream-Low-Power 
Vendor-Length 

6 


Value 


This field is a 4-byte unsigned integer, indicating the numeric 
value of the subscriber's DSL minimum downstream data rate. The 
rate is coded in bits per second. 
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3.3.13. Maximum-Interleaving-Delay-Upstream 
Description 
This Attribute contains the subscriber’s maximum one-way upstream 
interleaving delay, as configured by the operator. It MAY be 


included in Accounting-Request packets. 


A summary of the Maximum-Interleaving-Delay-Upstream Attribute format 
is shown below. The fields are transmitted from left to right. 


0 1 2 3 
0.1 23 45.6 7 8)9.01.2 3 4 5.6 78.9 012345078959 01 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 
139 (0x8B) for Maximum-Interleaving-Delay-Upstream 
Vendor-Length 
6 
Value 
This field is a 4-byte unsigned integer, indicating the numeric 
value in milliseconds of the subscriber's DSL maximum one-way 
upstream interleaving delay. 
3.3.14. Actual-Interleaving-Delay-Upstream 
Description 
This Attribute contains the subscriber's actual one-way upstream 
interleaving delay. It MAY be included in Accounting-Request 


packets. 


A summary of the Actual-Interleaving-Delay-Upstream Attribute format 
is shown below. The fields are transmitted from left to right. 
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0 1 2 3 
001.23 4-56 7 8.9 0.1.2 3 4 5-6.7 89.9.0. 1.2 3 4-36 7 8 9.01 
€———————R———————————A—A^A^AA^AW^AA———»4—4^—ARAR——»——————————! 

| vendor-Type | Vendor-Length | Value 

(——————W———————————————^——————————————M—— — 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Vendor-Type 
140 (0x8C) for Actual-Interleaving-Delay-Upstream 
Vendor-Length 
6 
Value 
This field is a 4-byte unsigned integer, indicating the numeric 
value in milliseconds of the subscriber's DSL actual upstream 
interleaving delay. 
3.3.15. Maximum-Interleaving-Delay-Downstream 
Description 
This Attribute contains the subscriber's maximum one-way 
downstream interleaving delay, as configured by the operator. It 
MAY be included in Accounting-Request packets. 
A summary of the Maximum-Interleaving-Delay-Downstream Attribute 
format is shown below. The fields are transmitted from left to 
right. 
0 1 2 3 
0 1.2.29 4 5.6 7.8:9-0.1 23.4 5.6 /:8 9 0 l2 23 4 5 6 7:8.9-0:.1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Value (cont'd.) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Vendor-Type 


141 (0x8D) for Maximum-Interleaving-Delay-Downstream 
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Vendor-Length 
6 
Value 


This field is a 4-byte unsigned integer, indicating the numeric 
value in milliseconds of the subscriber's DSL maximum one-way 
downstream interleaving delay. 


3.3.16.  Actual-Interleaving-Delay-Downstream 
Description 


This Attribute contains the subscriber's actual one-way downstream 
interleaving delay. It MAY be included in Accounting-Request 
packets. 


A summary of the Actual-Interleaving-Delay-Downstream Attribute 
format is shown below. The fields are transmitted from left to 
right. 


0 pi 2 3 
0-1.2-314.- 56 y 8 9 0.1 2 3 4 5-6 7-8 9 0 L2 3 4-5 Y 8-9:0 1 
dd + + + q + + q + + + + + +++ +++ +++ +++ +2+++++>3+ 

| Vendor-Type | Vendor-Length | Value 
dd + + + + + q + + + + ++ ++ ++ +++ ++ +++2++2++>+>+ 
Value (cont'd.) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Vendor-Type 

142 (0x8E) for Actual-Interleaving-Delay-Downstream 
Vendor-Length 

6 


Value 


This field is a 4-byte unsigned integer, indicating the numeric 
value in milliseconds of the subscriber's DSL actual downstream 
interleaving delay. 
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3.3.17.  Access-Loop-Encapsulation 
Description 


This Attribute describes the encapsulation(s) used by the 
subscriber on the DSL access loop. It MAY be present in both 
Access-Request and Accounting-Request packets. 


A summary of the Access-Loop-Encapsulation Attribute format is shown 
below. The fields are transmitted from left to right. 


0 I 2 3 
0123456789012345678°90123456789021 
dh A A A O A O A hh hh hh o o +++ 

| Vendor-Type | Vendor-Length | Value 
+-+-+-+-+-+-+-+-+-+-+-+- +++ 
Value (cont'd) | 

— — 


Vendor-Type 

144 (0x90) for Access-Loop-Encapsulation 
Vendor-Length 

5 
Value 


This field is a string 3 bytes in length, logically divided into 
three 1-byte sub-fields as shown in the following diagram: 


0 1 2 
0123456789 01234567890123 
+-+-4+-4+-+-+4+-4+-4+-+-4+-4+-+-4+-+-+-+-4-4+-+4-4+-4+-+-+4+-4-4+ 
| Data Link | Encaps 1 | Encaps 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Valid values for the sub-fields are as follows: 


Data Link 


0x01 AAL5 
0x02 Ethernet 
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Encaps 1 


0x00 
0x01 
0x02 


Encaps 2 


0x00 
0x01 
0x02 
0x03 
0x04 
0x05 
0x06 
0x07 
0x08 


DSL Forum RADIUS VSA 


NA - Not Available 
Untagged Ethernet 
Single-Tagged Ethernet 


NA - Not Available 
PPPoA LLC 

PPPoA Null 

IPoA LLC 

IPoA Null 


Ethernet over AAL5 LLC with FCS 
Ethernet over AAL5 LLC without FCS 
Ethernet over AAL5 Null with FCS 
Ethernet over AAL5 Null without FCS 


3.3.18.  IWF-Session 


Description 


September 2006 


The presence of this Attribute indicates that the IWF has been 


performed with respect to the subscriber's session; 
data field is necessary. It MAY be included in both Access- 


Request and Accounting-Request packets. 


note that no 


A summary of the IWF-Session Attribute format is shown below. The 


fields are transmitted from left to right. 


0 
01234 


1 
56789012345 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Vendor-Type | Vendor-Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Vendor-Type 


254 (OxFE) for IWF-Session 


Vendor-Length 


2 


Mammoliti, et 


al. Informational 


[Page 20] 


RFC 4679 DSL Forum RADIUS VSA September 2006 


4. Table of Attributes 


The following table provides a guide to which attributes may be found 
in which kinds of packets, and in what quantity; note that since none 
of the DSL Forum VSAs may be present in the Access-Accept, Access- 
Reject or Access-Challenge packets, those columns have been omitted 
from the table. 


Request Acct-Request # Attribute 
0-1 0-1 1 Agent-Circuit-Id 


0-1 0-1 2 Agent-Remote-Id 

0-1 0-1 129 Actual-Data-Rate-Upstream 

0-1 0-1 130 Actual-Data-Rate-Downstream 

0 0-1 131 Minimum-Data-Rate-Upstream 

0 0-1 132 Minimum-Data-Rate-Downstream 

0 0-1 133 Attainable-Data-Rate-Upstream 

0 0-1 134 Attainable-Data-Rate-Downstream 

0 0-1 135 Maximum-Data-Rate-Upstream 

0 0-1 136 Maximum-Data-Rate-Downstream 

0 0-1 137 Minimum-Data-Rate-Upstream-Low-Power 
0 0-1 138 Minimum-Data-Rate-Downstream-Low-Power 
0 0-1 139 Maximum-Interleaving-Delay-Upstream 

0 0-1 140 Actual-Interleaving-Delay-Upstream 

0 0-1 141 Maximum-Interleaving-Delay-Downstream 
0 0-1 142 Actual-Interleaving-Delay-Downstream 
0-1 0-1 144  Access-Loop-Encapsulation 

0-1 0-1 254  IWF-Session 


The following table defines the meaning of the above table entries. 


0 This Attribute MUST NOT be present in packet. 
0-1 Zero or one instances of this Attribute MAY be present in 
packet. 
5. Security Considerations 


The security of these Attributes relies on an implied trust 
relationship between the Access Node/DSLAM and the BRAS. The 
identifiers that are inserted by the Access Node/DSLAM are 
unconditionally trusted; the BRAS does not perform any validity check 
on the information received. These Attributes are intended to be 
used in environments in which the network infrastructure (the Access 
Node/DSLAM, the BRAS, and the entire network in which those two 
devices reside) is trusted and secure. 
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As used in this document, the word "trusted" implies that 
unauthorized traffic cannot enter the network except through secured 
and trusted devices and that all devices internal to the network are 
secure and trusted. Careful consideration should be given to the 
potential security vulnerabilities that are present in this model 
before deploying this option in actual networks. 


The Attributes described in this document neither increase nor 
decrease the security of the RADIUS protocol. For discussions of 
various RADIUS vulnerabilities, see [RFC2607], [RFC3579], [RFC3162], 
and [RFC3580]. 
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